Traditionally in web-based client-server environments, a web browser is used for displaying web pages sent by a server-side web application within a browser application frame. The web browser is also used for converting events triggered by one or more user actions within the browser application frame into a request directed to the server-side web application. As the browser functionality is small compared to stand-alone applications, this web-user interface may be considered as a “light” version compared to the user interface operated by a stand-alone application without an interconnected web connection.
With reference to FIG. 1, a prior art web-application, involving a web browser 12 as a “light” client having a low-level functionality user interface and an application server 14 hosting the application, suffers from a lack of interactivity with the user and from difficult programming models.
Typically a prior art web application works as follows:
On receipt of a user interaction 1 (e.g., a click on a link, pressing a button, pressing of one or more keys, or activation of any interactive component on a page of the web browser 12), the web browser makes a request to the application server 14 by sending a hypertext transfer protocol (HTTP) request 2 pointing to a uniform resource locator (URL). Possibly, a set of parameters to be interpreted by the application server 14 may be passed with the HTTP request 2. These parameters may contain information about the interaction the user did on the page and can be passed to the application server 14 either as URL-encoded parameters in an HTTP GET request or as data in the body of an HTTP POST request.
The request 2 is processed by a servlet 16 or a Java Server Page (JSP), which generates a hypertext mark-up language (HTML) document and sends the HTML document back to the web-browser 12 as a response 3.
The HTML document generated by the servlet 16 typically contains links or interactive elements with links to URLs (i.e., either to different servlets/JSPs, or to the same servlet 16 with different parameters).
When the user clicks on one of these interactive elements, the browser is redirected to the new URL. A new HTTP request is sent to the application server 14, which generates a complete new HTML document and sends it back to the web browser 12. The new document replaces the old one. Subsequent processing of user inputs includes receiving user actions 1, sending HTTP requests 2, and receiving responses 3.
However, there are several drawbacks to this general prior art approach:
First, since each user-interaction reloads an entire document, there is a long time delay between the user interaction and the visual response from the application, since the entire document has to be transmitted through a network before the document is displayed again by the web browser 12. Thus, it is not possible to build highly-interactive user interfaces where a large number of user events (e.g., mouse events or other user input) can be processed by the application server 14.
Second, a programming model to realize such applications is complex. Since each user interaction leads to the replacement of the current document with a new document, the logic of the web application program at the application server 14 becomes complicated, as current status information about the current session has to be passed to the application server 14 in order to be used in the new document.
Third, the programming model of the web application is completely different from the programming model of a standalone application. In a standalone offline application, user interface logic can be implemented within a single panel by listening to the events coming from the elements of the panel and responding with property changes in other elements of the same panel. For instance, when button A is clicked, the color of text B is changed. In a web application, every user-triggered event is associated with the generation of a new document. This makes porting standalone application user interface logic to a web application impossible without a complete reengineering of the user interface.
The reason for this drawback is found to be technical limitations of the client side. Web browsers were originally designed to display static content (text and images). Thus, web browsers offer very limited programming capabilities. Although numerous plug-ins have been developed to enhance the capabilities of the web browsers, the web browsers are basically still simple client software that can only send requests to a web server and display the returned documents.
To compensate for the lack of capabilities of the web browsers, several specific prior art solutions have been developed by the industry. Such solutions may comprise an executable program object which is used at the client side as a part of the client-side web application user interface. Examples of this executable code are scripts written in a scripting language (e.g., JavaScript, Dynamic HTML (DHTML), ECMA Script, or other scripting language) and applets (e.g., Java applets).
A scripting language can be used to modify the content of a displayed document. A script has to be defined in the document loaded by the web browser 12. The execution of the script is made by the web browser 12 itself. Thus, the application server 14 prepares the script, sends it to the web browser 12, but as soon as the document is displayed in the web browser 12, the application server 14 has no further influence on it.
The use of applets enables complete programs to be downloaded on the client. The applets are executed in the web browser 12.
These approaches have, however, considerable drawbacks. Scripting languages allow modification of “on-the-fly” elements of a displayed document without having to reload the whole document, but the scripts implementing this user interface behavior have to be fully defined in the original document downloaded from the application server 14. Once the document is loaded, the application server 14 does not interact anymore with the user interface and the script cannot be modified until a new document is loaded.
Applets are very flexible and can open additional communication channels with application servers (e.g., application server 14), but disadvantageously the whole code of the application to execute has to be downloaded to the client and executed by the web browser 12. This also involves some considerable problems. The problems may include length of time to download the document, security issues due to the applet, and compatibility issues with a virtual machine used by the web browser 12 to execute the applet.
Again with reference to FIG. 1, if the user interaction 1 can be processed locally by the web browser 12 (i.e., the reaction to this user interaction is defined in the JavaScript sent with the HTML document sent as the response 3), the scripts statically embedded in the page can process it and the process stops here. But this is not a satisfying solution due to the reasons described above.
Because of these drawbacks, web applications are still limited to components with a low interactivity (i.e., they generally include text fields, buttons, links in their user interface). Applications using complex mouse interactions (e.g., drag and drop of elements) are difficult to realize. It is thus an objective of the present disclosure to alleviate the disadvantages of the prior art.